|
| | Provides benefits of REST but allows adaptation to WS clients. This would still require support for the authorization mechanism to get keys, but could deliver the data for those users in a single batch, periodically (say, once per day), in the same format as the REST version. (Or, possibly, a simplified format without Atom or AtomPub elements). This would not allow on-demand requests, or flows from 3rd Parties to Utilities, but may be sufficient for some clients. |
| | | 1 (6%) | |
|
|
| | Like that it is considering devices now and not waiting until later as in WS-*. |
| | | 1 (6%) | |
|
|
| | Maturity of Toolsets and availability of industry expertise. |
| | | 1 (6%) | |
|
|
| | Define once and the result works for business to business as well as device to business allowing for a more vibrant ecosystem.
Simple, secure, better resource utilization and the direction the web is going. |
| | | 1 (6%) | |
|
|
| | From an implementation standpoint, Rest may be lighter weight and easier to implement on embedded devices. |
| | | 1 (6%) | |
|
|
| | Developers or industry stakeholders should be given the choice of use between two widely used WS interfaces (SOAP and REST). Both have their pros and cons and if an implementation framework is built that is independent of implementation specifics (e.g., security vs. richness of information, etc.), it would be better. |
| | | 1 (6%) | |
|
|
| | Security
Tools
Adoption as standard
Ideal for enterprise data transfer |
| | | 1 (6%) | |
|
|
| | WS tends to be a more heavyweight system, with more back and forth, and more complex parsing demands (being generally XML based). It is not obvious that that this adds value in the OpenADE domain, and REST interfaces are more likely to be implementable on a simple embedded device. Though OpenADE is more concerned with server to server communication, it seems an unnecessary complication to use a different interface for in home device, and it seems likely that they will bleed into one another. Also, implementing Web Service based projects is usually more costly for a given task. |
| | | 1 (6%) | |
|
|
| | Implementation ease, efficiency |
| | | 1 (6%) | |
|
|
| | My vote at a minimum that we standardize on SOAP due to the following items below. SOAP is a standard, REST is not. SMT Portal is based on SOAP functions as a base standard because we are doing more than transporting data which is primarily what REST is being designed for. I believe there is a possibility that both will be used in the future, but security or lack thereof in REST is a problem at the moment. I believe the group needs to recognize that the SMT Portal is not only data movement but B2B operations.
SOAP is sometimes criticized because of the barrage of web service and XML standards (some would say, encumbrances) that ride along with it - XSD, WSDL, WS-Addressing, WS-Policy, WS-Security, WS-Federation, WS-ReliableMessaging, WS-Coordination, WS-AtomicTransaction, WS-RemotePortlets, etc. You can develop highly complex, object-oriented, distributed applications with SOAP.
But for many applications, you don't need all the complexity of SOAP. REST stands for REpresentative State Transfer. It is simpler and has more humble capabilities. In particular though, it lacks standards around security. One might use it for very light-weight applications where security isn't a consideration or can be addressed outside the communications protocol.
You would not use REST for B2B applications, but might use it for selected internal applications.
|
| | | 1 (6%) | |
|
|
| | Easier method of programming behind REST. Market movement towards REST (vs. SOAP). |
| | | 1 (6%) | |
|
|
| | Growing Microsoft support for WS-Management |
| | | 1 (6%) | |
|
|
| | Most familiar with the WS-type interfaces. |
| | | 1 (6%) | |
|
|
| | Better aligned with other Internet-scale protocols, and the Smart Energy profile activities.
The WS* style is more suited for constrained, intranet type integrations. OpenADE is more of an external interface with not very complex semantics.
That said, Comverge does not have any strong preferences against WS-* either. But we would like to see an uniform approach in similar domains. |
| | | 1 (6%) | |
|
|
| | Performance
Flexibility
Light-weight and lighter on the network – especially for smart meter/device communications which are typically small packets
Security is easier to implement
|
| | | 1 (6%) | |
|
|
| | WS-* standards should be easier to get through committee as we push OpenADE "up the chain". |
| | | 1 (6%) | |
|
|
Total: 16 |